Архитектура хранения¶
Tarantool Column Store – колоночная транзакционно-аналитическая СУБД, построенная на платформе Tarantool Enterprise Edition. TCS наследует от Tarantool базовые возможности хранения и масштабирования:
данные хранятся в оперативной памяти;
хранение персистентно;
доступны механизмы репликации и шардирования.
TCS относится к гибридному классу систем хранения HTAP (Hybrid transactional/analytical processing). Хранилище данных реализовано средствами in-memory СУБД Tarantool. Для работы с данными в колоночном формате используется движок обработки данных MemCS. Такая архитектура позволяет добиться оптимальной производительности аналитических запросов (OLAP) наряду с характерной для Tarantool высокой производительностью при транзакционной нагрузке (OLTP).
Ниже описаны детали реализации основных механизмов TCS:
Колоночное хранение¶
Основное хранилище данных TCS работает с данными в колоночном формате.
Ключевое отличие колоночных СУБД от реляционных СУБД с табличным хранением – использование колонки в качестве единицы хранения вместо таблицы. В реляционной СУБД все поля одного объекта хранятся рядом в виде одной строки таблицы. В свою очередь, в колоночной рядом располагаются все значения одного поля таблицы, а поля одного объекта разнесены по соответствующим колонкам и не хранятся вместе.
Использование колоночного формата позволяет оптимизировать работу TCS под нагрузкой, характерной для аналитических задач (OLAP), то есть при большом количестве запросов на чтение и вычисление агрегатов.
Чтение данных¶
Как гибридное решение, TCS предполагает работу под транзакционной нагрузкой на запись. Для консистентности чтения данных в таких условиях TCS использует представления для чтения (read view) – снимки хранилища данных в конкретный момент времени.
В каждый момент времени в TCS существует одно актуальное представление на чтение.
Оно обновляется раз в rv_update_ms миллисекунд. Когда приходит запрос
на чтение данных, для него используется актуальное представление.
Чтение выполняется в многопоточном режиме. Каждый поток, выполняющий запрос на чтение,
использует свое представление. В системе хранится набор всех используемых в данный момент
представлений, то есть тех, из которых еще выполняется чтение в рамках выполнения запросов.
Когда обработка запроса завершена, и при этом уже создано более актуальное представление,
то представление, которые использовалось для этого запроса, помещается в очередь
на удаление. Представления из этой очереди удаляются при следующей итерации цикла
сборщика мусора (раз в rv_update_ms миллисекунд).
Подробнее о представлениях на чтение см. документацию Tarantool EE.
Доступ к данным¶
Доступ к данным осуществляется по протоколам SQL Arrow Flight и HTTP. Запросы по всем протоколам принимаются в формате SQL.
В зависимости от режима работы кластера, запросы можно отсылать:
напрямую на узлы-хранилища (Storage) – они обрабатывают все виды запросов к данным;
через узлы-маршрутизаторы (Scheduler) – они автоматически перенаправляют запросы на узлы Storage.
Режимы работы кластера¶
Кластер TCS может работать в одном из двух режимов: проксирования или шардирования.
В режиме проксирования:
В каждом экземпляре БД в кластере хранятся одинаковые данные.
Запросы от клиентов могут автоматически перенаправляться на узлы Storage с помощью узлов Scheduler.
При необходимости возможно отсылать запросы напрямую на конкретный узел Storage.
В режиме шардирования:
В разных экземплярах БД хранятся разные части общего массива данных.
С помощью узлов Scheduler, запросы от клиентов автоматически перенаправляются на узлы Storage с учетом разбиения данных на шарды.
Отсылать запросы напрямую на конкретный узел Storage запрещено.